Normally, the need to perform database recovery arises after a database system has failed, such as after a power failure or a system crash. In order to preserve the integrity of the data stored in the database, the database system must bring the database back to the latest consistent state which existed prior to the failure. If, for example, a system crash occurs in the middle of a fund transfer between two accounts at a bank, the reasonable way of recovery would be to reset the database to the state it was in just before the fund transfer was initiated, and then redo the transfer again afterwards. Otherwise, the bank may not be able to guarantee that for example money was not withdrawn from one of the accounts even though the money never reached the other account before the crash.
In addition to the above, the need to perform database recovery may arise also for other reasons. One such reason is that of forensic analysis, where a need to recover data that may have been voluntarily deleted or modified is sometimes paramount. When a file containing data is deleted from, or modified on, e.g. a hard drive, the operating system usually only updates its file system metadata where e.g. the location of a particular file on the hard drive is stored. If a file is deleted, the metadata is updated, while the actual data of the file (as written to the hard drive) is left untouched. Thus, even though the file system metadata is updated, or missing, a forensic analyst can use methods such as data carving in an attempt to locate and read the original data of a deleted or modified file. Many of the methods of data carving, such as e.g. pattern searching, are often complex and rely on both complex models and heuristics. In addition to the problem that the number of different possible permutations of scattered (or fragmented) data is often large, the methods may also suffer from the fact that the outcome is not always guaranteed to be correct. A data carving method may end up piecing several fragments from several different files together into what it believes to be a single file, thus generating a false result (a false positive). If the number of false positives becomes too great, the job of the forensic analyst becomes difficult and the trustworthiness of the result may quickly degrade.
A more reliable method for recovering (un)intentionally deleted or modified data in a database may be to use the logging functionality often used by many database systems. To be able to bring a database back (i.e. to perform a database rollback) to a previous state, the database system may keep track of the actions that are performed on the database (i.e. the changes to the database) by using a so called write-ahead log (a WAL). When an action is impending on a database, a database system using a WAL will not update the database directly. Instead, the database system will determine the outcome of the action and record the changes that would have been made to the database to the log instead. In the event of a system failure during the time an action is performed, the database will already be in a consistent state, and the database system may easily check the WAL to see how far it got before the system failed, and then make a decision on how to proceed from there. In order for the WAL not to grow too large, the recorded changes in the WAL can be transferred back to the database either on regular occasions (such as after each action is successfully completed, or a lot more sparsely than so if wanted) or when triggered manually. Such an operation, known as a checkpoint operation, is usually followed by the WAL being reset such that new, to the checkpoint subsequent, changes are recorded from the start of the WAL again.
A method using a WAL to recover a database from a system failure is disclosed in U.S. Pat. No. 8,683,262. There, the WAL is first filtered such that irrelevant actions (e.g. actions that are later made ineffectual by other, subsequent, actions) are ignored in order to reduce computational complexity. Using the filtered WAL, the database is transitioned from a recovery state to a normal operation state by replaying the remaining actions in the filtered WAL. Since the main focus of the disclosed method is to restore a database after a failure, situations may arise where the method is of little or no use to a forensic analyst.
In light of the above, an improved, more flexible, more reliable and for forensic analysis more suitable method for performing database rollback to a previous state of a database using a WAL is thus required.